home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 3⁄23⁄90 / 0966-Off-Screen Bitmaps (-Mar90 < prev    next >
Encoding:
Text File  |  1990-03-23  |  6.5 KB  |  236 lines  |  [TEXT/GEOL]

  1. Item    3920875                         22-March-90        18:20PST
  2.  
  3. From:   D2652                           Strategic Planning Sys, D Bell,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Off-Screen Bitmaps (long)
  8.  
  9.  
  10.     TO: MacApp.Tech$
  11.     FR: D2652, Dan Cooley, Strategic Planning Systems
  12.     RE: MA Views and Off-screen Bitmaps
  13.  
  14. Hello fellow MacAppers!  I Have some comments and questions concerning the
  15. OSImage off-screen bitmapping package and MacApp views.  I have been using
  16. OSImage for some time now in our last project for some simple off-screen
  17. drawing and on-screen scrolling.   Our current project requires a bit more than
  18. that.
  19.  
  20. The ideal goal is to somehow incorporate OSImage into the view heirarchy so
  21. that any number fo views and subviews in a window will do their thing and all
  22. get blasted back into the window.
  23.  
  24. Well, I started thinking (and we all know how dangerous that is), and my first
  25. atempt was something like so.  I created a subcall of TWindow and overrode the
  26. .DrawContents method to something like this:
  27.  
  28. PROCEDURE TMyOldWindow.DrawContents; OVERRIDE;
  29. VAR
  30.    aRect   :   Rect;
  31.    savedPort   :   GrafPtr;
  32.    hTheDevice  :   GDHandle;
  33.    itsQDExtent :   Rect;
  34. BEGIN
  35.    HLock(Handle(SELF));
  36.  
  37.    GetGrafEnv(savedPort, hTheDevice);
  38.  
  39.    {$PUSH} {$H-}
  40.    SetOSGrafEnv(fOSImage.fOsip, fOSImage.fDstRect, fOSImage.fOsip);
  41.    {$POP}
  42.  
  43.    INHERITED DrawContents;
  44.  
  45.    SetGrafEnv(savedPort, hTheDevice);
  46.  
  47.    {$PUSH} {$H-}
  48.    CopyBits(fOSImage.fOsip^.portbits, thePort^.portBits,
  49.    fOSImage.fDstRect, fOSImage.fDstRect, srcCopy, NIL);
  50.    {$POP}
  51.  
  52.    HUnlock(Handle(SELF));
  53. END;
  54.  
  55.  
  56. I thought, great!! How simple and elegent.  But alas, this does not work
  57. because of the focusing methods needed in the MacApp view architecture.  Every
  58. subview would focus and bomb the program because of a 'Port set incorrectly'
  59. error, or something or other.  As far as I can tell, the only place to SAFELY
  60. use OSImage is within the .Draw methods of any view object type.
  61.  
  62. My second attempt developed into a two part solution.  I sublassed TWindow
  63. again and created the TOSImage object for it.  Then all the subviews were
  64. modified to draw into the window's fOSImage object.  Here is the code for my
  65. modified TWindow subclass:
  66.  
  67.  
  68. PROCEDURE TOSWindow.IRes(itsDocument: TDocument;
  69.    itsSuperview: TView;
  70.    VAR itsParams: Ptr); OVERRIDE;
  71.  
  72. VAR
  73.    anOSImage   :   TOSImage;
  74.    someRect:   Rect;
  75.    wp  :   WindowPtr;
  76. BEGIN
  77.    INHERITED IRes(itsDocument, itsSuperview, itsParams);
  78.    fOSImage := NIL;
  79.    { create the TOSImage object here }
  80. END;
  81.  
  82.  
  83.  
  84.  
  85. PROCEDURE TOSWindow.Update; OVERRIDE;
  86. VAR
  87.    aRect   :   Rect;
  88. BEGIN
  89.    IF Focus THEN BEGIN
  90.    GetQDExtent(aRect);
  91.    InvalidRect(aRect);   { we do this for our needs, but not neccesary? }
  92.  
  93.    INHERITED Update;
  94.    END;
  95.  
  96. END;
  97.  
  98.  
  99.  
  100. PROCEDURE TOSWindow.Draw(area: Rect); OVERRIDE;
  101. BEGIN
  102.    { do nothing to avoid that fashing on every redraw }
  103.  { TWindow.Draw performs an EraseRect call, but we don't want that }
  104. END;
  105.  
  106.  
  107.  
  108. PROCEDURE TOSWindow.DrawContents; OVERRIDE;
  109. VAR
  110.    aRect   :   Rect;
  111.    savedPort   :   GrafPtr;
  112.    hTheDevice  :   GDHandle;
  113.    itsQDExtent :   Rect;
  114. BEGIN
  115.    HLock(Handle(SELF));
  116.  
  117.    GetGrafEnv(savedPort, hTheDevice);  { set up to the offscreen bitmap }
  118.  
  119.    {$PUSH} {$H-}
  120.    SetOSGrafEnv(fOSImage.fOsip, fOSImage.fDstRect, fOSImage.fOsip);
  121.    {$POP}
  122.  
  123.    GetQDExtent(itsQDExtent);   { We know its extent always fits in
  124.      QuickDraw coordinates. }
  125.    EraseRect(itsQDExtent); { clear the offscreen bitmap}
  126.                                 { should we do this in .Draw??? }
  127.  
  128.    SetGrafEnv(savedPort, hTheDevice);  {set it back to normal }
  129.  
  130.    INHERITED DrawContents;
  131.  
  132.    {$PUSH} {$H-}
  133.    CopyBits(fOSImage.fOsip^.portbits, thePort^.portBits,
  134.    fOSImage.fDstRect, fOSImage.fDstRect, srcCopy, NIL);
  135.    {$POP}
  136.  
  137.    HUnlock(Handle(SELF));
  138. END;
  139.  
  140.  
  141.  
  142. PROCEDURE TOSWindow.Resize(width, height: VCoordinate;
  143.    invalidate: BOOLEAN); OVERRIDE;
  144. VAR
  145.    aRect   :   Rect;
  146.    didIt   :   BOOLEAN;
  147. BEGIN
  148.    INHERITED Resize(width, height, invalidate);
  149.  
  150.    IF (fOSImage <> NIL) & Focus THEN BEGIN
  151.    GetQDExtent(aRect);
  152.    didIt := fOSImage.Adjust(aRect);
  153.    END;
  154. END;
  155.  
  156.  
  157.  
  158. PROCEDURE TOSWindow.Free; OVERRIDE;
  159. BEGIN
  160.    FreeObject(fOSImage);
  161.    INHERITED Free;
  162. END;
  163.  
  164.  
  165.  
  166.  
  167. Here is a sample of the code I use to draw in the OffScreen bitmap:
  168.  
  169.  
  170.    PROCEDURE TMyView.Draw(area: Rect); OVERRIDE;
  171.    VAR
  172.    itsQDExtent :   Rect;
  173.    aString :   Str255;
  174.    savedPort   :   GrafPtr;
  175.    hTheDevice  :   GDHandle;
  176.    anOSImage   :   TOSImage;
  177.    aRect   :   Rect;
  178.  
  179.    BEGIN
  180.    HLock(Handle(SELF));
  181.  
  182.    GetGrafEnv(savedPort, hTheDevice);   { save the current grafport stuff }
  183.  
  184.    anOSImage := TOSWindow(GetWindow).fOSImage;
  185.    {$PUSH} {$H-}
  186.    SetOSGrafEnv(anOSImage.fOsip, anOSImage.fDstRect, anOSImage.fOsip);
  187.    {$POP}   { switch the WINDOW's OSImage object }
  188.  
  189.    PenNormal;
  190.    PenMode(srcOr);  { for layers, we want to see thru everything }
  191.  
  192.    {Set font and size for subsequent display in the window}
  193.    TextFont(ApplFont);
  194.    TextSize(72);
  195.  
  196.    MoveTo(50, 50);
  197.    DrawString('Hello');{ Draw the word 'Hello' in large type. }
  198.  
  199.    SetGrafEnv(savedPort, hTheDevice);
  200.  
  201.    HUnlock(Handle(SELF));
  202.    END;
  203.  
  204.  
  205. For our current needs this is fine.  But it has several blatant faults to it.
  206. First, all subviews draw relative to the windows OSImage bounds, that is they
  207. all draw relative to the upper left corner of the window.  Second, all subviews
  208. of a subview do the same.  Essentially, it removes MacApp's nifty view
  209. architecture.
  210.  
  211. So my first question is, how do I maintain a subview's local corrdinates and
  212. it's relative position to it's superview while using OSImage.  How do I
  213. maintain all of MacApp views properties while still drawing off-screen.  Do I
  214. need to create an off-screen bitmap for each subview, or can I draw into one
  215. like I do above?
  216.  
  217. Second, would this kind of thing be something to consider for some future
  218. version of the Guerrilla MacApp, like the scalable views.  Maybe a flag in the
  219. TView object like .fDrawOffScreen that would be set in a superview and equal in
  220. a subviews.   If that flag was TRUE then it would create its own OSImage
  221. object, and draw into that, plus all of its subviews too.
  222.  
  223. My personal opinion is that off-screen bitmaps are something almost every
  224. Macintosh programmer eventually tackles.  It would be nice if it were cleanly
  225. integrated into MacApp.  Chalk another mark on the wish list.
  226.  
  227. It sounds like a lot of work to implement, but if the interest is high... well
  228. let's just see how high before I go on...
  229.  
  230. I look forward to your feedback.
  231.  
  232. Dan Cooley
  233. Strategic Planning Systems
  234. ALink: D2652
  235.  
  236.